The small panel at the top-left of the Structure Spec tab shows 2 measures to help you understand the coverage of the Structure Spec, and the conformance of the source code.

The %Specified grows towards 100% as the spec extends deeper into the package structure. It looks at how many classes are contained by the leaf containers in the Spec – if this is more than 60, the package is not considered to be fully specified. You can easily find such package by clicking on the Unspecified items list to the left of the editor. The class counts for each container are shown next to it’s name in the list, and can optionally be displayed in the editor (enabled from the "Viewing options" menu).

The #Violations is a count of the number of times the currently loaded codebase violates the spec. There are 2 distinct kinds of violations:

1. Dependency violations. This is the number of references in the code that violate the spec
2. Item violations. These are items that were found in the code, in a scope that is included in the spec, but for which there is no corresponding item in the spec. For instance if the contents of package com.a is specified to contain com.a.x and com.a.y, but a package com.a.z is also found in the codebase, then the latter is in violation. The value associated with Item violations is the number of classes in the violating items.

When you start using Structure101 Studio you will have no spec at all, so your %Specified and #Violations will both be 0.

Typically in Java, projects and modules (Maven, Gradle, IDEA, ...) are not cyclically dependent and so can be fully levelized. This means that your initial (default) Structure Spec may also show no violations, and depending on the size of your projects, you will start with a low-ish %Specified, e.g. 30%.

As you increase the coverage of your spec by adding packaging, you may increase the #Violations temporarily until the code is refactored to bring it into line. Then you might add the contents of the next package to the spec, and so on.